Verdict

Approve. Clean, narrow fix that closes the asymmetry left by #842: the __player runtime adapter now honours { keepPlaying: true } so A/E Jump-to-in/out shortcuts preserve playback for window.__player-backed compositions, just like the wrapTimeline (GSAP) path already did. Type contract is propagated end-to-end (PlayerAPI → RuntimePlayer → createPlayerApiCompat basePlayer shape), implementation mirrors the existing play() body, and the 6 new tests cover the meaningful branches including the wasPlaying === false no-op and the explicit keepPlaying: false back-compat case.

Spot-checked claims against source:

• useTimelinePlayer.getAdapter() does return win.__player directly (no wrapper) — usePlaybackKeyboard.ts A/E handlers do pass { keepPlaying: true } — wrapTimeline.seek skips its internal tl.pause() when keepPlaying is set. All check out.
• seekMasterAndSiblingTimelinesDeterministically does pause the master and re-pause rearmed siblings, so the new branch correctly has to call timeline.play() + iterate siblings to resume — matches the symmetric pattern in play() (lines 117–129).
• wasPlaying is captured before the deterministic seek; the helper manipulates timelines but never touches isPlaying state, so the read is accurate.

Key Concerns

None blocking.

Test Coverage

Solid. The invocationCallOrder assertion in "resumes the master timeline after the deterministic seek pauses it" is a good way to express "play() must come after the helper's pause()" — that's exactly the regression vector. Coverage:

• keepPlaying: true && wasPlaying → preserves state, emits onDeterministicPlay + onShowNativeVideos + onSyncMedia(_, true) ✓
• keepPlaying: true && !wasPlaying → stays paused (intent is preserve, not force) ✓
• keepPlaying: false explicit → default path ✓
• No options → default path (back-compat) ✓
• Sibling timeScale + play() propagation ✓
• Master play() ordered after the helper's pause() ✓

Gap (non-blocking): no studio-side integration test in useTimelinePlayer.seek.test.ts exercising A/E → adapter.seek(_, { keepPlaying: true }) against the runtime adapter. The unit coverage is sufficient given options pass straight through useTimelinePlayer.seek → adapter.seek and the studio test suite passes, but a single end-to-end assertion would catch a future delegate regression.

Nits / Future

1. createStaticSeekPlaybackAdapter type drift (out of scope, called out in PR). Worth tightening the type now — it's a one-line change and the body already preserves playback by accident. Leaving the type signature mismatched is a footgun for the next person who reads the adapter and thinks keepPlaying is unhandled. Happy to follow up in a separate PR if you'd rather keep this one tight.

2. Sibling play→pause→play churn. During a keepPlaying seek, each sibling sees play() (rearm) → pause() (helper finally block) → play() (this branch). Functionally correct, but three GSAP state transitions per seek per sibling. Plumbing keepPlaying into seekMasterAndSiblingTimelinesDeterministically so it skips the final pause when the caller is going to immediately resume would be cleaner. Optimization, not a bug.

3. onDeterministicPause is never emitted by seek(), regardless of branch. This matches the prior behaviour (the original seek only emitted onDeterministicSeek), so no regression — flagging only because the play/pause methods do emit their paired onDeterministicPlay/onDeterministicPause, and an external listener relying on pair-symmetry could be surprised. Probably intentional, but worth being aware of.

4. setIsPlaying(true) is not called in the keep-playing branch. Fine because wasPlaying === true means state is already true, but it makes the branch slightly asymmetric to play() (which always emits setIsPlaying(true)). Not worth changing — just noting for future readers.

Nice cleanup of the loose end from #842.